[Bug fortran/40377] New: gfortran documentation: Add note to C prog. part + update F200x status
The GNU Fortran manual should mention in the mixed-language programming section that C's A[i][j] matches Fortran's A(j,i) and that A(j+1,i) follows A(j,i) in memory. Cf. http://gcc.gnu.org/onlinedocs/gfortran/Mixed_002dLanguage-Programming.html * * * The Fortran 2003/2009 status should be updated based on: http://gcc.gnu.org/wiki/Fortran2003 http://gcc.gnu.org/wiki/Fortran2003Status http://gcc.gnu.org/wiki/Fortran2008Status http://gcc.gnu.org/wiki/GFortran#news Release notes, e.g., http://gcc.gnu.org/gcc-4.4/changes.html cf. http://gcc.gnu.org/onlinedocs/gfortran/Fortran-2003-and-2008-status.html -- Summary: gfortran documentation: Add note to C prog. part + update F200x status Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40377
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-06-08 07:51 --- Hi, to define UNICODE is absolutely correct. The define _UNICODE is fiction (but I agree it is in use). We can discuss about to define _UNICODE, too. But the UNICODE defines is for the w64 runtime the proper thing to define here. Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #2 from ktietz at gcc dot gnu dot org 2009-06-08 08:31 --- Ok, it is no fiction, but a issue for tchar.h in CRT headers. See http://blogs.msdn.com/oldnewthing/archive/2004/02/12/71851.aspx so, we define UNICODE for PSDK, but _UNICODE is user defined AFAIU. But possibly we could add the _UNICODE define for CRT's sake, too. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #88 from bonzini at gnu dot org 2009-06-08 08:40 --- Created an attachment (id=17963) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17963&action=view) patch I'm testing Here is a patch I'm testing that completes the rewrite of fwprop's dataflow. This should make it much faster and less memory hungry. It should also keep the generated code fast (with -frename-registers of course), if not it's a bug in the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/40372] [4.4/4.5 Regression] ICE with invalid use of non-static data members
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-08 08:58 --- Caused by PR28879 (r144988) fix. build_nop doesn't build a NOP_EXPR if the argument or its type is error_mark_node, so: 13318 /* Remember this wasn't a constant-expression. */ 13319 bounds = build_nop (TREE_TYPE (bounds), bounds); 13320 TREE_SIDE_EFFECTS (bounds) = 1; would set TREE_SIDE_EFFECTS (error_mark_node). Which of course breaks a lot of code everywhere. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-08 08:58:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40372
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #89 from bonzini at gnu dot org 2009-06-08 08:59 --- Created an attachment (id=17964) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17964&action=view) correct version oops, the previous one didn't work at -O1 even though it bootstrapped :-) -- bonzini at gnu dot org changed: What|Removed |Added Attachment #17963|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-06-08 09:09 --- As further research has shown, is the definition of _UNICODE a thing the user has to take care. The _UNICODE define is used in tchar.h and documentation for this can be found on msdn. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-08 09:11 --- See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/fc7bdedfa4afc785 and note that the realloc shall not always happen: If has TARGET attribute and the size is the same, no pointer to may break. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
[Bug c++/40370] [4.4/4.5 Regression] ICE with invalid array bound in template class
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-08 09:33:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #4 from joseph at codesourcery dot com 2009-06-08 09:40 ---
Subject: Re: GCC defines UNICODE instead of _UNICODE
for -municode
On Mon, 8 Jun 2009, ktietz at gcc dot gnu dot org wrote:
> to define UNICODE is absolutely correct. The define _UNICODE is fiction (but I
UNICODE is in the user's namespace; it should not be predefined if
flag_iso (if you have to use specs rather than hooks, you need
%{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance
options). We should not add to the instances of bug 545 that are still
present. If the MinGW headers use a macro in the user's namespace as a
feature test macro of some sort, they are buggy and should be fixed (with
fixincludes if necessary for existing installations).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #9 from matevz dot tadel at cern dot ch 2009-06-08 10:42 --- Replying to comment 7: > do you require all equivalenced vars to be either threadprivate > or non-threadprivate? > or, does a single threadprivate var make all vars equivalenced somehow to > it threadprivate? It would be cleaner and less ambiguous if all equivalenced commons/variables are required to be declared threadprivate. > There is a problem for saved variables - there the equivalence does not work. > One has two options: > 1. Remove the equivalence statements and replace the aliases in the code. > 2. Create a "local" common block with the saved variables. If the variables > were initialized via data statements one has to take care of that at the > first entry into the routine. This was more a technical comment as SAVE statement was not discussed before and in our legacy code we also had 3 such occurrences (equivalence among saved array elements and local variables). The patch does not address the SAVEd variables, so an error is still generated. Potentially the scope of the patch could be extended to also cover the SAVE statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug middle-end/40253] [4.5 Regression] label emitted for debug has no reference?
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-06-08 11:03 --- *** This bug has been marked as a duplicate of 40126 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40253
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-06-08 11:03 --- *** Bug 40253 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||marcus at jet dot franken ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #10 from matz at gcc dot gnu dot org 2009-06-08 11:37 --- Subject: Bug 40012 Author: matz Date: Mon Jun 8 11:37:12 2009 New Revision: 148273 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148273 Log: PR debug/40012 * cfgexpand.c (set_rtl): Store place also in DECL_RTL, if all partitions use the same. (expand_one_var): Deal with DECL_RTL sometimes begin set also for basevars of SSA_NAMEs. (expand_used_vars): Reset TREE_USED for basevars of SSA_NAMEs, to not expand them twice. (gimple_expand_cfg): Clear DECL_RTL for those decls that have multiple places. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #11 from matz at gcc dot gnu dot org 2009-06-08 11:38 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug target/40375] redundant register move with -mthumb
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-08 11:41 --- "might be" is such a useless statement. Carrot, you are aware of the -fdump-rtl-all and -dAP options, I assume? Then you should have no trouble finding out: 1) Where the move comes from 2) Why postreload (the post-reload CSE pass) does not eliminate the redundant move -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug c/40378] New: ICE starting with revision 147980
internal compiler error: in generate_subtree_copies, at tree-sra.c:1702 while building linux kernel starting with gcc 4.5.0 revision 147980 -- Summary: ICE starting with revision 147980 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: denis dot onischenko at gmail dot com GCC build triplet: x86_64-cross-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug c/40378] ICE starting with revision 147980
--- Comment #1 from denis dot onischenko at gmail dot com 2009-06-08 11:57 --- Created an attachment (id=17965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17965&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug c/40378] ICE starting with revision 147980
--- Comment #2 from denis dot onischenko at gmail dot com 2009-06-08 11:58 --- Created an attachment (id=17966) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17966&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #6 from reichelt at gcc dot gnu dot org 2009-06-08 12:03
---
The testcase from comment #2 doesn't show the bug anymore.
Here's a slightly modified version that does:
typedef struct A
{
int i : 2;
struct A *p;
} A;
static int f1(A *t)
{
if (t->i)
return 0;
return t->i;
}
static A *f2(A *t)
{
if (t->i)
return f2(t->p);
else
return t;
}
static int f3(A *t)
{
return f1(f2(t));
}
static int f4(A *t)
{
if (f3(f2(t)))
g(0, 0, 0, 0, 0, 0, 0);
return t->i;
}
int f5(A *t)
{
return f3(t);
}
static int f6(A *t)
{
return f5(t) || f5(f2(t));
}
static int f7(A *t)
{
return f6(t) || f4(t);
}
int foo(A *t)
{
return f7(t);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug c/40378] ICE starting with revision 147980
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-08 13:27 --- This is obviously mine. Will look into it shortly. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-08 13:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug middle-end/40378] ICE starting with revision 147980
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-08 14:01 --- It is caused by revision 143502: http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00515.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-08 14:01:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #16 from dennis dot wassel at googlemail dot com 2009-06-08 14:26 --- Hi, with Günther's last status report (2009-05-21) saying that there might be a release in late June, is there any chance that this can be fixed till 4.4.1? Thanks, Dennis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #17 from dennis dot wassel at googlemail dot com 2009-06-08 14:28 --- (In reply to comment #16) > with Günther's last status report [...] Now that's just stupid - sorry Richard! (German mistake) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-08 14:47 --- Created an attachment (id=17967) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17967&action=view) gcc45-pr40373.patch Possible fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-08 15:31 --- *** Bug 40378 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||denis dot onischenko at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug middle-end/40378] ICE starting with revision 147980
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-08 15:31 --- *** This bug has been marked as a duplicate of 40351 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40378
[Bug rtl-optimization/40361] Conditional return not always profitable with -Os
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40361
[Bug middle-end/40364] ICE in in purge_dead_edges, at cfgrtl.c:2325 compiling MAME
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-08 15:37 --- Probably related to PR39886 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39886 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40364
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-08 15:39 --- The gcc.gnu.org frontpage lists the three active development lines. Anything else is unsupported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug tree-optimization/18031] OR of a bitfield and a constant is not optimized at tree level
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-06-08 15:40 --- Thus fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-08 15:42 --- WONTFIX for 4.3/4.4 branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|4.3.4 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug c/40368] -foptimize-sibling-calls drops assignment from tail call
--- Comment #9 from john at iastate dot edu 2009-06-08 15:42 --- Subject: Re: -foptimize-sibling-calls drops assignment from tail call > The gcc.gnu.org frontpage lists the three active development lines. > Anything else is unsupported. Thank you for the clarification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40368
[Bug target/40375] redundant register move with -mthumb
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug c++/40357] [4.5 Regression] compiler hang for C++ code
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-08 15:50 ---
#7 0x004fbcf6 in start_function (declspecs=0x7fffdbb0,
declarator=0x18717e0, attrs=0x0) at ../../../src/trunk/gcc/cp/decl.c:11884
11884 decl1 = grokdeclarator (declarator, declspecs, FUNCDEF, 1, &attrs);
(gdb) down
#6 0x004e927b in grokdeclarator (declarator=0x18716a0,
declspecs=0x7fffdbb0, decl_context=NORMAL, initialized=1,
attrlist=0x7fffd9d8) at ../../../src/trunk/gcc/cp/decl.c:9403
9403decl = grokfndecl (ctype, type, original_name, parms,
unqualified_id,
(gdb)
#5 0x004deeac in grokfndecl (ctype=0x75347780,
type=0x751adf00, declarator=0x76964a80, parms=0x7519bcf0,
orig_declarator=0x76964a80, virtualp=0, flags=NO_SPECIAL, quals=0,
raises=0x0, check=1, friendp=0, publicp=1, inlinep=0, sfk=sfk_none,
funcdef_flag=1 '\1', template_count=0, in_namespace=0x0,
attrlist=0x7fffd9d8, location=11072845)
at ../../../src/trunk/gcc/cp/decl.c:6867
6867 ok = duplicate_decls (decl, old_decl, friendp);
#4 0x004c117f in duplicate_decls (newdecl=0x751a0300,
olddecl=0x75135900, newdecl_is_friend=0 '\0')
at ../../../src/trunk/gcc/cp/decl.c:1694
1694 newtype = merge_types (TREE_TYPE (newdecl), TREE_TYPE (olddecl));
(gdb)
#3 0x00624c30 in merge_types (t1=0x751add80, t2=0x753b1b40)
at ../../../src/trunk/gcc/cp/typeck.c:764
764 t3 = merge_types (t1, t2);
(gdb)
#2 0x0062454f in merge_types (t1=0x751add80, t2=0x753b1b40)
at ../../../src/trunk/gcc/cp/typeck.c:716
716 tree valtype = merge_types (TREE_TYPE (t1), TREE_TYPE (t2));
(gdb)
#1 0x00623867 in merge_types (t1=0x75187c00, t2=0x753b1a80)
at ../../../src/trunk/gcc/cp/typeck.c:629
629 if (original_type (t1) == original_type (t2))
(gdb)
#0 0x0062045d in original_type (t=0x753b1480)
at ../../../src/trunk/gcc/cp/typeck.c:238
238 && TYPE_NAME (t) != NULL_TREE)
(gdb) finish
Run till exit from #0 0x0062045d in original_type (t=0x753b1480)
at ../../../src/trunk/gcc/cp/typeck.c:238
and hangs...
233 static tree
234 original_type (tree t)
235 {
236 int quals = cp_type_quals (t);
237 while (t != error_mark_node
238 && TYPE_NAME (t) != NULL_TREE)
239 {
240 tree x = TYPE_NAME (t);
241 if (TREE_CODE (x) != TYPE_DECL)
242 break;
(gdb) l
243 x = DECL_ORIGINAL_TYPE (x);
244 if (x == NULL_TREE)
245 break;
246 t = x;
247 }
doesn't finish if DECL_ORIGINAL_TYPE (x) is the same as t.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2009-06-08 15:50:18
date||
Summary|compiler hang for C++ code |[4.5 Regression] compiler
||hang for C++ code
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40357
[Bug middle-end/40223] cgraph_estimate_size_after_inlining missmatch
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-06-08 15:54 --- The loops should be in sync, but I am but confused here. I originally added the code only when walking types, not actual declarations, since in decls we don't use that VOIDtype terminator. There was some side case where declaration actually had VOID argument in C++, but I don't recall the exact scenario. There is gcc_assert (!VOID_TYPE_P (type)) in estimate_move_cost I would expect to fire if we was ever compiling function having VOID in the parm list. How did you fire the >= 0 assert? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40223
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #4 from jason at gcc dot gnu dot org 2009-06-08 16:19 --- I think it should be fixed in 4.3/4.4 since the bug wasn't present in 4.3.3 and the fix is trivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[g++] The template parameter hidden by outer member.
Dear developpers,
My environment is
- GCC 4.3.2
- Debian 5.0 AMD 64
- compile option is none, I compiled testprogram is as follows
- g++ -o program-name source-file-name
- compiler outputs no error and warning
The template parameter which is declared in a class is hidden by
outer class member when the template parameter is used in the
class method.
see following code,
#include
using namespace std;
struct test
{
const static int value = 1;
template struct inner1 {
const static int inner_value = value;
int get_value() { return value; }
};
};
int main()
{
test::inner1<2> t1;
cout << t1.inner_value << endl;
cout << t1.get_value() << endl;
}
The output is as follows
2
1
I think the outer variable name should not hide the inner template
parameter. Therefore, the correct output is as follows.
2
2
Best regards,
Toshihiko Ando.
[Bug c++/40372] [4.4/4.5 Regression] ICE with invalid use of non-static data members
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-08 16:26 --- Subject: Bug 40372 Author: jakub Date: Mon Jun 8 16:26:01 2009 New Revision: 148278 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148278 Log: PR c++/40370 PR c++/40372 * parser.c (cp_parser_direct_declarator): Don't set TREE_SIDE_EFFECTS on error_mark_node. Check for VLAs outside of function context before check whether to wrap bounds into a NOP_EXPR with TREE_SIDE_EFFECTS. * g++.dg/template/error41.C: New test. * g++.dg/template/error42.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/error41.C trunk/gcc/testsuite/g++.dg/template/error42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40372
[Bug c++/40370] [4.4/4.5 Regression] ICE with invalid array bound in template class
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-08 16:26 --- Subject: Bug 40370 Author: jakub Date: Mon Jun 8 16:26:01 2009 New Revision: 148278 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148278 Log: PR c++/40370 PR c++/40372 * parser.c (cp_parser_direct_declarator): Don't set TREE_SIDE_EFFECTS on error_mark_node. Check for VLAs outside of function context before check whether to wrap bounds into a NOP_EXPR with TREE_SIDE_EFFECTS. * g++.dg/template/error41.C: New test. * g++.dg/template/error42.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/error41.C trunk/gcc/testsuite/g++.dg/template/error42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
[Bug c++/40370] [4.4/4.5 Regression] ICE with invalid array bound in template class
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-08 16:31 --- Subject: Bug 40370 Author: jakub Date: Mon Jun 8 16:31:07 2009 New Revision: 148281 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148281 Log: PR c++/40370 PR c++/40372 * parser.c (cp_parser_direct_declarator): Don't set TREE_SIDE_EFFECTS on error_mark_node. Check for VLAs outside of function context before check whether to wrap bounds into a NOP_EXPR with TREE_SIDE_EFFECTS. * g++.dg/template/error41.C: New test. * g++.dg/template/error42.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/error41.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/error42.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
[Bug c++/40372] [4.4/4.5 Regression] ICE with invalid use of non-static data members
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-08 16:31 --- Subject: Bug 40372 Author: jakub Date: Mon Jun 8 16:31:07 2009 New Revision: 148281 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148281 Log: PR c++/40370 PR c++/40372 * parser.c (cp_parser_direct_declarator): Don't set TREE_SIDE_EFFECTS on error_mark_node. Check for VLAs outside of function context before check whether to wrap bounds into a NOP_EXPR with TREE_SIDE_EFFECTS. * g++.dg/template/error41.C: New test. * g++.dg/template/error42.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/error41.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/error42.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40372
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #90 from bonzini at gnu dot org 2009-06-08 16:35 --- Yo, with the patch the time to compile compiler.i with the given options is 331s on my machine (with a checking compiler). Fwprop takes only 1% (including computation of the new dataflow problem). I'd estimate around 250s with your nonchecking build. I'll split it and post it tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/40372] [4.4/4.5 Regression] ICE with invalid use of non-static data members
--- Comment #4 from jakub at gcc dot gnu dot org 2009-06-08 16:40 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40372
[Bug c++/40370] [4.4/4.5 Regression] ICE with invalid array bound in template class
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-08 16:40 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #5 from jakub at gcc dot gnu dot org 2009-06-08 16:48 --- Subject: Bug 40373 Author: jakub Date: Mon Jun 8 16:48:11 2009 New Revision: 148282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148282 Log: PR c++/40373 * call.c (check_dtor_name): Return false even if get_type_value (name) is error_mark_node. * g++.dg/template/dtor7.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/dtor7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #6 from jakub at gcc dot gnu dot org 2009-06-08 16:49 --- Subject: Bug 40373 Author: jakub Date: Mon Jun 8 16:49:17 2009 New Revision: 148283 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148283 Log: PR c++/40373 * call.c (check_dtor_name): Return false even if get_type_value (name) is error_mark_node. * g++.dg/template/dtor7.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/dtor7.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/call.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #7 from jakub at gcc dot gnu dot org 2009-06-08 17:02 --- Subject: Bug 40373 Author: jakub Date: Mon Jun 8 17:02:17 2009 New Revision: 148284 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148284 Log: PR c++/40373 * call.c (check_dtor_name): Return false even if get_type_value (name) is error_mark_node. * g++.dg/template/dtor7.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/dtor7.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/call.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug c++/40373] [4.3/4.4/4.5 Regression] ICE with invalid destructor call
--- Comment #8 from jakub at gcc dot gnu dot org 2009-06-08 17:03 --- Fixed for 4.3/4.4/4.5. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.0 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40373
[Bug c++/40379] New: Extremely long compiling time of gcc optimization mode
I've got some cpp files that take extremely long time to compile with gcc-4.2.3 in the optimization mode. For example, one of them takes 102 minutes elapsed time. This is the command line I used (I've removed -I -D -MMD -MT -MF and -MP options). $ /usr/bin/time g++ -m32 -xc++ -c -fPIC -pipe -fpermissive -w -fuse-cxa-atexit -march=athlon64 -mfpmath=sse -O2 -o 5936.75user 2.94system 1:42:47elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (2major+440942minor)pagefaults 0swaps If I remove the "-O2" option, the compilation takes less than 11 seconds. It looks like that the optimization stage is spending very long time. I've tried to modify my source code, and one change has made the difference. There are many functions in several anonymous namespace in the cpp file. If I name those namespace to make them non-anonymouse. The compilation time is reduced to about 4 minutes. It seems to me that gcc is spending a lot of time inlining those functions, presumably because those function are called only once. I would like to know whether there are some gcc options to avoid this lengthy optimization time without changing the source code or disabling the -O2 option altogether. I tried to compile with -fno-unit-at-a-time and -fno-inline-functions-called-once, but they do not seem to affect the compiling time. The system I am using is Red Hat Enterprise Linux AS release 4 (Nahant Update 4) on x86_64 processor. I compiled gcc 4.2.3 myself with the following config: $ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2.3/configure --prefix=/home/share/gcc-4.2.3 --enable-__cxa_atexit --enable-languages=c,c++ --enable-multilib Thread model: posix gcc version 4.2.3 -- Summary: Extremely long compiling time of gcc optimization mode Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: qingning dot huo at barcap dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40379
[Bug middle-end/40102] [4.5 Regression] Revision 147294 caused ICE: verify_cgraph_node
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-06-08 17:18 --- Subject: Bug 40102 Author: hubicka Date: Mon Jun 8 17:17:52 2009 New Revision: 148287 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148287 Log: PR middle-end/40102 * cgraph.c (cgraph_create_edge_including_clones): Also asume that the original node might've been modified. * tree-inline.c (copy_bb): Do not assume that all clones are the same. PR middle-end/40102 * g++.dg/torture/pr40102.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr40102.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40102
[Bug middle-end/40102] [4.5 Regression] Revision 147294 caused ICE: verify_cgraph_node
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-06-08 17:20 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40102
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #17 from jamborm at gcc dot gnu dot org 2009-06-08 17:49 --- (In reply to comment #16) > Wait, (In reply to comment #15) > > (In reply to comment #11) > > > It is caused by revision 147980: > > > > > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html > > > > > > > Revision 147978 also does not work if you compile the testcase with > > the -fno-tree-sra switch. > > > > New SRA uncovers this problem because it sees the structure containing > > only a single field always accessed as a structure and never as a > > scalar and so does not scalarize it. Something goes wrong later on, > > probably when expanding to RTL. Unfortunately, I cannot help fixing > > that. > > I think that should always scalarize as it is a single field as it is always > better to scalarize single field structs (except maybe bitfield ones). Well, Richi seems to disagree: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00637.html I am not sure myself, I believe that there are not so many cases in which this would prove beneficial. When there are no operations performed on the scalars, the only situation I can think of would be some extensive copy propagation. Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug middle-end/32950] [4.5 regression] ICE with __complex__ double
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-06-08 17:50 --- (In reply to comment #17) > I am not sure myself, I believe that there are not so many cases in > which this would prove beneficial. When there are no operations > performed on the scalars, the only situation I can think of would be > some extensive copy propagation. Or the case where expand does something stupid which does happen one time or another. I think for unions it should always happen no matter what (because unions have the mode set to BLKmode). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32950
[Bug tree-optimization/20165] Pointer does not really escape with write
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-06-08 18:12 --- This also causes missed warnings about unitizialized variables: $ cat foo.f print *,x end $ gfortran -O3 -Wall -Wextra foo.f We should have some way of marking that pointer as read-only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20165
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #91 from lucier at math dot purdue dot edu 2009-06-08 18:19 --- Created an attachment (id=17968) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17968&action=view) time and memory report for compiler.i after Paolo's patch The patch cut the total bitmaps used compiling compiler.i from > 60GB to 3GB; maximum memory (just from top) was 1631MB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/40362] openmp: some libgomp functions trigger data races
--- Comment #8 from bart dot vanassche at gmail dot com 2009-06-08 18:30 --- (In reply to comment #7) Thanks for the feedback. I'll use the above information to suppress the complaints on thr->ts.work_share->next_ws and will post the results here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-06-08 18:34 --- OK, problem seems to be that we keep stale location list hash that confuse dwarf2out when outputting abstract function Index: dwarf2out.c === --- dwarf2out.c (revision 148287) +++ dwarf2out.c (working copy) @@ -13792,6 +13792,7 @@ dwarf2out_abstract_function (tree decl) /* Make sure we have the actual abstract inline, not a clone. */ decl = DECL_ORIGIN (decl); + htab_empty (decl_loc_table); old_die = lookup_decl_die (decl); if (old_die && get_AT (old_die, DW_AT_inline)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug fortran/40377] gfortran documentation: Add note to C prog. part + update F200x status
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-08 19:02 ---
As this is my texi cleanup bug: Dump the following in order to not forget it.
Index: intrinsic.texi
===
--- intrinsic.texi (Revision 148274)
+++ intrinsic.texi
@@ -11241,6 +11241,11 @@
Identifies the preconnected unit identified by the asterisk
(@code{*}) in @code{READ} statement.
+...@item @code{INT8}, @code{INT16}, @code{INT32}, @code{INT64}
+Kind type parameters to specify an INTEGER type with a storage
+size of 16, 32, and 64 bits. It is negative if a target platform
+does not support the particular kind.
+
@item @code{IOSTAT_END}:
The value assigned to the variable passed to the IOSTAT= specifier of
an input/output statement if an end-of-file condition occurred.
@@ -11255,8 +11260,15 @@
@item @code{OUTPUT_UNIT}:
Identifies the preconnected unit identified by the asterisk
(@code{*}) in @code{WRITE} statement.
+
+...@item @code{REAL32}, @code{REAL64}, @code{REAL128}
+Kind type parameters to specify an INTEGER type with a storage
+size of 32, 64, and 128 bits. It is negative if a target platform
+does not support the particular kind.
@end table
+
+
@node ISO_C_BINDING
@section @code{ISO_C_BINDING}
@table @asis
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40377
[Bug middle-end/40379] Extremely long compiling time of gcc optimization mode
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-08 19:05 --- GCC 4.2 is no longer maintained, please update to at least 4.3.3, preferably to 4.4.0 and reproduce there. To do anything about this we need a testcase which would be preprocessed source. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40379
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #6 from dalej at gcc dot gnu dot org 2009-06-08 19:17 --- That needs to be parenthesized differently; if that's fixed, I have no objection to doing it that way, but since all MachO targets have SSE, that works too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug middle-end/39834] [4.5 Regression] verify_cgraph_node failed with -O3 -Winline
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-06-08 19:21 --- Subject: Bug 39834 Author: hubicka Date: Mon Jun 8 19:21:33 2009 New Revision: 148292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148292 Log: PR debug/39834 * gcc.dg/torture/pr39834.c PR middle-end/39834 * cgraphunit.c (save_inline_function_body): Do not copy transform hooks for saved inline bodies. * ipa-passes.c (do_per_function): Do not add the hoks multiple times for given function. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39834.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39834
[Bug middle-end/39834] [4.5 Regression] verify_cgraph_node failed with -O3 -Winline
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-06-08 19:22 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39834
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-06-08 19:26 --- Subject: Bug 40126 Author: hubicka Date: Mon Jun 8 19:25:51 2009 New Revision: 148293 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148293 Log: PR debug/40126 * dwarf2out.c (dwarf2out_abstract_function): Free decl_loc_table. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #9 from hubicka at gcc dot gnu dot org 2009-06-08 19:26 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug middle-end/39284] Computed gotos combined too aggressively
--- Comment #8 from hubicka at gcc dot gnu dot org 2009-06-08 20:55 --- Hmm, the conditional is bogus, there should not be ! but still after patching this we don't duplicate. The reason is that the BB 71 (containing conditional jump) is reached via 2 BBs containing memory load. I guess it is result of crossjumping. I will send patch fixing the conditional, but it makes little difference. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
[Bug target/34115] atomic builtins not supported on i686?
--- Comment #10 from joseph dot h dot garvin at gmail dot com 2009-06-08
21:18 ---
After encountering this issue and some testing, I think this is definitely a
bug. The problem ONLY occurs when directly returning a call to an atomic
builtin! Assuming no march flags:
Links:
int main()
{
unsigned long test;
return __sync_add_and_fetch(&test, 1);
return (int)test;
}
Does not link:
int main()
{
unsigned long test;
return __sync_add_and_fetch(&test, 1);
}
If you do specify -march=i686, then they both link! If this somehow isn't a
bug, the design is poor, because it's very hard to debug behavior.
$ gcc -v
Reading specs from
/opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-solaris2.10/4.2.2/specs
Target: i386-pc-solaris2.10
Configured with: ../configure --prefix=/opt/app/g++lib6/gcc-4.2
--enable-languages=c,c++,fortran,objc --disable-nls --with-included-gettext
--with-gnu-as --with-as=/usr/sfw/bin/gas --with-target-tools=/usr/sfw/bin/
--with-gmp=/opt/app/nonc++/gmp-4.2 --with-mpfr=/opt/app/nonc++/mpfr-2.3
Thread model: posix
gcc version 4.2.2
--
joseph dot h dot garvin at gmail dot com changed:
What|Removed |Added
CC||joseph dot h dot garvin at
||gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
[Bug libstdc++/40380] New: class documentation should mention include file to use
I was reading the documentation for unique_ptr: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00587.html This mentions unique_ptr.h -- but that is not a user-allowed header file. Instead the user ought to write "#include ". This is not mentioned anywhere, but IMO it should be. -- Summary: class documentation should mention include file to use Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380
[Bug c++/40370] [4.4/4.5 Regression] ICE with invalid array bound in template class
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-06-08 21:54 --- Thanks, Jakub. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40370
[Bug middle-end/39284] Computed gotos combined too aggressively
--- Comment #9 from steven at gcc dot gnu dot org 2009-06-08 22:43 --- There shouldn't be a "!". Just make use optimize_function_for_speed_p(cfun). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
[Bug middle-end/39284] Computed gotos combined too aggressively
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-08 22:45 --- Honza, what do the basic blocks 2 and 71 look like for you, exactly? I see no memory load. But I have local crossjumping patches -- as you know ;-) -- so I am probably not looking at the same dumps as you are. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
[Bug tree-optimization/29751] not optimizing access a[0] , a[1]
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-09 02:35 --- I have a simple patch (which needs some cleanups but it works). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |pinskia at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29751
[Bug middle-end/35360] Static (base/offset/size rule) should be extended to handle array elements
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-09 02:40 ---
Here is another testcase that depends on PRE/FRE (really VN) getting the more
correct answer:
struct A{
int a;
int b;
};
struct A aa[100];
void foo(int n, int i, int j)
{
aa[j].a = 0;
aa[i].b = 1;
if (aa[j].a != 0)
link_error();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35360
[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:15 --- Subject: Bug 40334 Author: jvdelisle Date: Tue Jun 9 03:15:04 2009 New Revision: 148303 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148303 Log: 2009-06-08 Jerry DeLisle PR libfortran/40334 * io/list_read.c (list_formatted_read_scalar): Set the end file conditions after a return from EOF error. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:18 --- Subject: Bug 40334 Author: jvdelisle Date: Tue Jun 9 03:18:30 2009 New Revision: 148304 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148304 Log: 2009-06-08 Jerry DeLisle PR libfortran/40334 * gfortran.dg/backspace_11.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/backspace_11.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:19 --- Fixed on 4.4 and 4.5 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug libfortran/38654] Fortran I/O speedup
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-06-09 03:21 --- I think we are done with this. Reopen if more suggestions. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38654
[Bug target/40375] redundant register move with -mthumb
--- Comment #4 from carrot at google dot com 2009-06-09 03:46 ---
Thank you, Steven.
(In reply to comment #3)
> "might be" is such a useless statement.
>
> Carrot, you are aware of the -fdump-rtl-all and -dAP options, I assume? Then
> you should have no trouble finding out:
> 1) Where the move comes from
This is rtl dump before RA, everything is in normal state:
cat obj/reg.c.173r.asmcons
;; Function test (test)
(note 1 0 5 NOTE_INSN_DELETED)
(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 3 2 src/./reg.c:3 (set (reg/v/f:SI 133 [ name ])
(reg:SI 0 r0 [ name ])) 168 {*thumb1_movsi_insn} (expr_list:REG_DEAD
(reg:SI 0 r0 [ name ])
(nil)))
(insn 3 2 4 2 src/./reg.c:3 (set (reg/v:SI 134 [ style ])
(reg:SI 1 r1 [ style ])) 168 {*thumb1_movsi_insn} (expr_list:REG_DEAD
(reg:SI 1 r1 [ style ])
(nil)))
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 8 2 src/./reg.c:4 (set (reg:SI 0 r0)
(const_int 0 [0x0])) 168 {*thumb1_movsi_insn} (nil))
(insn 8 7 9 2 src/./reg.c:4 (set (reg:SI 1 r1)
(reg/v/f:SI 133 [ name ])) 168 {*thumb1_movsi_insn} (expr_list:REG_DEAD
(reg/v/f:SI 133 [ name ])
(nil)))
(insn 9 8 10 2 src/./reg.c:4 (set (reg:SI 2 r2)
(reg/v:SI 134 [ style ])) 168 {*thumb1_movsi_insn} (expr_list:REG_DEAD
(reg/v:SI 134 [ style ])
(nil)))
(call_insn 10 9 0 2 src/./reg.c:4 (parallel [
(call (mem:SI (symbol_ref:SI ("foo") [flags 0x41] ) [0 S4 A32])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 256 {*call_insn} (expr_list:REG_DEAD (reg:SI 2 r2)
(expr_list:REG_DEAD (reg:SI 1 r1)
(expr_list:REG_DEAD (reg:SI 0 r0)
(nil
(expr_list:REG_DEP_TRUE (use (reg:SI 2 r2))
(expr_list:REG_DEP_TRUE (use (reg:SI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
(nil)
Here is rtl dump after RA, quite straightforward but inefficient:
(note 1 0 5 NOTE_INSN_DELETED)
(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 3 2 src/./reg.c:3 (set (reg/v/f:SI 3 r3 [orig:133 name ] [133])
(reg:SI 0 r0 [ name ])) 168 {*thumb1_movsi_insn} (nil))
(insn 3 2 4 2 src/./reg.c:3 (set (reg/v:SI 2 r2 [orig:134 style ] [134])
(reg:SI 1 r1 [ style ])) 168 {*thumb1_movsi_insn} (nil))
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 8 2 src/./reg.c:4 (set (reg:SI 0 r0)
(const_int 0 [0x0])) 168 {*thumb1_movsi_insn} (nil))
(insn 8 7 10 2 src/./reg.c:4 (set (reg:SI 1 r1)
(reg/v/f:SI 3 r3 [orig:133 name ] [133])) 168 {*thumb1_movsi_insn}
(nil))
(call_insn 10 8 18 2 src/./reg.c:4 (parallel [
(call (mem:SI (symbol_ref:SI ("foo") [flags 0x41] ) [0 S4 A32])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 256 {*call_insn} (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 2 r2))
(expr_list:REG_DEP_TRUE (use (reg:SI 1 r1))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
(nil)
(note 18 10 0 NOTE_INSN_DELETED)
> 2) Why postreload (the post-reload CSE pass) does not eliminate the redundant
> move
>
It seems the post-reload CSE pass can't handle this case. Because at
instruction C r0 is killed so instruction can't use r0. In order to make it
work for this case we must move instruction D before C first.
As Andrew said we need to improve scheduling before RA to handle this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-09 06:52 ---
(In reply to comment #4)
> Subject: Re: GCC defines UNICODE instead of _UNICODE
> for -municode
>
> UNICODE is in the user's namespace; it should not be predefined if
> flag_iso (if you have to use specs rather than hooks, you need
> %{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance
> options). We should not add to the instances of bug 545 that are still
> present. If the MinGW headers use a macro in the user's namespace as a
> feature test macro of some sort, they are buggy and should be fixed (with
> fixincludes if necessary for existing installations).
>
It is right that _UNICODE and UNICODE are in user name space defined and are
controlling which API (wide/or ascii) has to be used.
UNICODE is used in windows headers itself (see msdn for documentation).
_UNICODE is used in CRT (and inspecial in tchar.h header) only. (This is also
documented in msdn).
I agree, that these two different macro names are a bit annoying, but for sure
they are platform specific stuff and are for sure absolutely unrelated to ISO.
Therefore to introduce a relationship to ISO defines is contradictive and
wrong. Those macros are controling behaviour of runtime. By the windows
specific switch -municode the windows runtime is controlled.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug c++/40381] [4.4/4.5 Regression] ICE with defaulted functions
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug c++/40381] New: [4.4/4.5 Regression] ICE with defaulted functions
The following invalid code snippet triggers an ICE since GCC 4.4.0:
==
struct A
{
template void foo(T) = delete;
};
template void A::foo(T) {}
void bar()
{
A().foo(0);
}
==
bug.cc:6:27: error: redefinition of 'void A::foo(T)'
bug.cc:3:29: error: 'void A::foo(T)' previously declared here
bug.cc: In function 'void bar()':
bug.cc:3:29: error: deleted function 'void A::foo(T) [with T = int]'
bug.cc:10:12: error: used here
bug.cc: In member function 'void A::foo(T) [with T = int]':
bug.cc:10:12: instantiated from here
bug.cc:6:38: internal compiler error: in finish_function, at cp/decl.c:12250
Please submit a full bug report, [etc.]
By modifying the definition of foo, I can provoke crashes in different parts
of the compiler:
template void A::foo(T) { A(); }
yields
bug.cc:6:39: internal compiler error: in poplevel, at cp/decl.c:536
and
template void A::foo(T) { return; }
yields
bug1C.cc:6:39: internal compiler error: Segmentation fault
This is a regression as the compiler crashes even without -std=gnu++0x.
--
Summary: [4.4/4.5 Regression] ICE with defaulted functions
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
