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: re
--
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
--- 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 th
--- 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
--- 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
---
--- 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
--- 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
--- 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
--- 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
--- 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
-
--- 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.
--
--- 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
--- 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
Statu
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.
--
--- 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()
--- 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
--- 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
--- 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_abstr
--- 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
--- 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
--- 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
--- 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 g
--- 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)
+++ in
--- 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
===
--- dwarf2
--- 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/sh
--- 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 c
--- 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://
--- 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 situ
--- 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
> > >
> >
> > Revi
--- 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
--- 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
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 -fperm
--- 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
Stat
--- 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 f
--- 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 f
--- 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 f
--- 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
--- 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
--- 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
--- 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_
--- 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_
--- 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_
--- 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_
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 whe
--- 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
--- 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
--- 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,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||missed-op
--- 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:
--- 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
--- 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|NE
--- 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
--- 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
BugsTh
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40361
--- 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
--
--- 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
---
--- 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
--- 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
--- 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/bugz
--- 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
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
-
--- 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;
--- 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
--- 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
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
Severit
--- 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-r
--- 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
--- 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 pla
--- 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
--- 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
---
--- 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
--- 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
UNICOD
--
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
--- 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 ma
--- 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
--- 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 or
--- 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 (b
--- 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 mu
--- 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 co
--- 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
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
82 matches
Mail list logo
