--- Comment #3 from janus at gcc dot gnu dot org 2009-08-25 09:08 ---
The patch in comment #2 was successfully bootstrapped and regtested. Ok for
trunk?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41149
--- Comment #4 from rguenther at suse dot de 2009-08-25 09:13 ---
Subject: Re: -fdump-tree-original and procedure pointer
components
On Tue, 25 Aug 2009, janus at gcc dot gnu dot org wrote:
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-25 09:08 ---
The patch in
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-25 09:35 ---
Subject: Bug 41149
Author: janus
Date: Tue Aug 25 09:35:41 2009
New Revision: 151075
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151075
Log:
2009-08-25 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-25 09:38 ---
Fixed with r151075. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from mahatma at eu dot by 2009-08-25 10:20 ---
Fix: I got bug with -msse only, not -msse2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-25 10:35 ---
/space/rguenther/trunk/gcc/testsuite/g++.old-deja/g++.pt/spec26.C:11:36:
internal compiler error: canonical types differ for identical types const X []
and const X []^M
Please submit a full bug report,^M
with
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-08-25 10:36 ---
Ok I fixed at revision 151077 the issues about gthr-win32.h, the objective-c
library warnings aren't fixed by this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34315
--- Comment #7 from steven at gcc dot gnu dot org 2009-08-25 11:21 ---
Please drop the patch in gcc-patches as well (just post it with a comment that
you've committed it to fix this PR).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41149
--- Comment #9 from dominiq at lps dot ens dot fr 2009-08-25 11:55 ---
I see a similar slowdown with the patch in
http://gcc.gnu.org/ml/fortran/2009-08/msg00361.html (see
http://gcc.gnu.org/ml/fortran/2009-08/msg00377.html). I suspect it is related
to pr41098, but I don't know how to
--- Comment #10 from dominiq at lps dot ens dot fr 2009-08-25 12:01 ---
I see a similar slowdown with the patch in ...
I have again forgotten to say that I saw the slowdown without the -fwhole-file
option.
I have changed the summary to reflect that.
--
dominiq at lps dot ens dot
--- Comment #9 from developer at sandoe-acoustics dot co dot uk 2009-08-25
12:06 ---
(In reply to comment #7)
Use --enable-stage1-languages=c,c++
I believe that this bug also applies to powerpc-apple-darwin8 and
i686-apple-darwin9.
the suggested remedy also works.
This was
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-25 12:22
---
We clone quite a few functions with -fwhole-file but appearantly we fail to
apply constant propagation for CONST_DECL arguments which is a pity. In fact
we seem to clone them without any change.
--
rguenth at
--- Comment #12 from dominiq at lps dot ens dot fr 2009-08-25 12:30 ---
From comment #9, I think inlining is just exposing a latent missed optimization
related to the way the middle end handle pow(). This is why I changed the
summary.
--
--- Comment #13 from rguenther at suse dot de 2009-08-25 12:40 ---
Subject: Re: Time increase with inlining for the
Polyhedron test air.f90
On Tue, 25 Aug 2009, dominiq at lps dot ens dot fr wrote:
--- Comment #12 from dominiq at lps dot ens dot fr 2009-08-25 12:30
---
--- Comment #14 from dominiq at lps dot ens dot fr 2009-08-25 12:51 ---
I don't think the issue is pow expansion.
What I do see from different means is that the number of calls to pow()
increases from 63,907,869 to 1,953,139,629. Since pow() is not exactly cheap, I
think this could
--- Comment #2 from bangerth at gmail dot com 2009-08-25 13:24 ---
Why would this be ambiguous? A string literal has type array of n const char
(see 2.13.4/1), so it should go with the array constructor. Do you disagree?
W.
--
bangerth at gmail dot com changed:
What
--- Comment #8 from bangerth at gmail dot com 2009-08-25 13:27 ---
Already confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #7 from bangerth at gmail dot com 2009-08-25 13:29 ---
I would think so.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #4 from bangerth at gmail dot com 2009-08-25 13:31 ---
*** Bug 41104 has been marked as a duplicate of this bug. ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 13:31 ---
Yes, I think this is an exact duplicate.
*** This bug has been marked as a duplicate of 23055 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
Attached .i file throws
--
$ gcc -c grep.i
grep.i: In function âcmd_grepâ:
grep.i:9236:5: error: type mismatch in address expression
struct option[unknown] *
struct option[41] *
options.0 = options;
grep.i:9236:5: internal compiler error: verify_gimple failed
Please submit a
--- Comment #1 from hideaki at sogetthis dot com 2009-08-25 13:36 ---
Created an attachment (id=18422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18422action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41163
--- Comment #1 from bangerth at gmail dot com 2009-08-25 13:43 ---
This is an interesting one:
enum EE {ee};
struct D {
enum EE : 8;
};
In C++98, this looks like an unnamed bit field as part of struct D, but
with C++0x we
--- Comment #4 from bangerth at gmail dot com 2009-08-25 13:59 ---
gcc 3.3 has not been maintained for a long time. Since you say that gcc 4.0
fixes the bug, I think we can close the bug.
W.
--
bangerth at gmail dot com changed:
What|Removed
--
bangerth at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41161
--- Comment #3 from bangerth at gmail dot com 2009-08-25 13:54 ---
Hm, can you try to come up with a smaller testcase for which it may be a bit
simpler to see what is going on?
Thanks
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-25 13:53 ---
*** Bug 41054 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at gmail dot com 2009-08-25 14:04 ---
Confirmed:
-
class A {
template int struct s {
enum { value };
};
};
int i = A::s10::value;
-
This should produce an error but doesn't.
W.
--
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-25 13:53 ---
I think this is a duplicate of PR 16663, just a different testcase. One can
possibly construct a lot of different testcases for mispelled/undefined types,
depending on the context where the declaration takes place
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:10 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:13 ---
With current mainline, I just get these errors:
g/x /home/bangerth/bin/x86/gcc-mainline/bin/c++ x.cc -std=c++0x
x.cc:4:36: error: '__int128_t' was not declared in this scope
x.cc:5:36: error: '__uint128_t' was not
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:15 ---
Confirmed. Very odd.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at gmail dot com 2009-08-25 14:16 ---
Confirmed. An ICE. I haven't checked the accepts-invalid part.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #3 from v dot haisman at sh dot cvut dot cz 2009-08-25 14:20
---
(In reply to comment #2)
Why would this be ambiguous? A string literal has type array of n const char
(see 2.13.4/1), so it should go with the array constructor. Do you disagree?
W.
IANALL, but I think
--- Comment #5 from bangerth at gmail dot com 2009-08-25 14:25 ---
Jonathan, the point everyone is trying to make is this: since no function
or function template matches the call, all the compiler could possibly
do is list all declarations of the name staticPrint() or none, but of
--- Comment #17 from janus at gcc dot gnu dot org 2009-08-25 14:27 ---
Subject: Bug 41139
Author: janus
Date: Tue Aug 25 14:26:44 2009
New Revision: 151081
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151081
Log:
2009-08-25 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #18 from janus at gcc dot gnu dot org 2009-08-25 14:29 ---
Fixed with r151081. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
With this compiler:
heine:~/programs/gambc-v4_5_1-devel /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline --enable-languages=c,c++
-enable-stage1-languages=c,c++
Since PR 25104 and PR 29962, gfortran allows PRODUCT in initialization
expressions (2009-06-07); however, using -std=f95 PRODUCT is still accepted.
Expected: Print an error when using -std=f95.
INTEGER, PARAMETER :: d = 4 ! Number of elements to permute
INTEGER :: I
INTEGER, PARAMETER :: maxnum
--- Comment #2 from bangerth at gmail dot com 2009-08-25 14:39 ---
Hm, confusing:
-
enum E {e};
struct A {
A(int);
explicit A(E) {};
};
int main () { A a = e; }
-
This compiles but not links becase A::A(int) is called. If
--- Comment #4 from tom at kera dot name 2009-08-25 14:48 ---
(In reply to comment #2)
Why would this be ambiguous? A string literal has type array of n const char
(see 2.13.4/1), so it should go with the array constructor. Do you disagree?
W.
Table 9 under 13.3.3/1 shows that
--- Comment #2 from joseph at codesourcery dot com 2009-08-25 14:48 ---
Subject: Re: undefined reference to `typeinfo for __int128'
On Tue, 25 Aug 2009, bangerth at gmail dot com wrote:
With current mainline, I just get these errors:
g/x
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-25 14:57
---
Created an attachment (id=18423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18423action=view)
test file that illustrates failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164
Revision 151015 gave
../src-trunk/contrib/test_summary | sh
sh: -c: line 0: unexpected EOF while looking for matching `'
sh: -c: line 1: syntax error: unexpected end of file
Revision 151012 is OK.
--
Summary: [4.5 Regression] Syntax error: Unterminated quoted
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:24 ---
Confirmed:
-
template class T struct Base {
template class D class I {};
};
--- Comment #3 from kretz at kde dot org 2009-08-25 15:26 ---
Actually I came across this problem because my code was failing on MSVC and
icc. Then I noticed that icc compiles the code, the one that I pasted,
differently. On further investigation I decided that gcc is at fault and that
--- Comment #3 from bangerth at gmail dot com 2009-08-25 15:26 ---
Confirmed with gcc4.2.1.
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
Last
--- Comment #3 from bangerth at gmail dot com 2009-08-25 15:30 ---
Can you try to come up with a smaller, possibly self-contained testcase
that would make it simpler for us to determine what's going on? Take a
look here regarding what would help us:
http://gcc.gnu.org/bugs.html
W.
--- Comment #15 from dominiq at lps dot ens dot fr 2009-08-25 15:30 ---
I think I have made some progress to understand the problem:
(1) The 1,953,139,629 or so calls to pow() are the non optimized base.
(2) For working situations this number is reduced to 63,907,869 or so when
using
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-25 15:31 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41163
--- Comment #2 from bangerth at gmail dot com 2009-08-25 15:31 ---
Confirmed. A regression.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:34 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #2 from bangerth at gmail dot com 2009-08-25 15:35 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:35 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-25 15:37 ---
Confirmed.
struct option {
void *value;
};
void parse_options (struct option *);
void cmd_grep(void)
{
struct option options[] = { { options } };
parse_options(options);
}
--
rguenth at gcc dot gnu
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:39 ---
Hm, interesting. I would have thought as well that the code should compile.
On the other hand, icc also produces the same error message, so I am now
officially confused...
--
bangerth at gmail dot com changed:
--- Comment #3 from bangerth at gmail dot com 2009-08-25 15:40 ---
Also works on gcc4.3.2, so apparently fixed everywhere.
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:42 ---
Yes, this is confusing.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:44 ---
Confirmed. Not a regression.
--
bangerth at gmail dot com changed:
What|Removed |Added
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40535
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40775
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40808
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40968
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41038
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41085
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41087
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:49 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41109
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41127
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:51 ---
Confirmed. This is indeed awkward, and not actually all that hard to get
into using makefiles (was @ the input or output file again??).
--
bangerth at gmail dot com changed:
What|Removed
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40224
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41162
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41166
--- Comment #1 from rwild at gcc dot gnu dot org 2009-08-25 15:57 ---
AFACIS, the bug is in the test_summary script, it tries to parse the
internals of a config.status file. To extract values from config.status
portably (across both systems and Autoconf versions), use either an
Hi,
the following code leads to an ICE:
% cat gfcbug88.f90
program gfcbug88
implicit none
type t
character(len=8) :: name
end type t
type(t) ,parameter :: obstyp(2)= (/ t ('A'), t ('B') /)
print *, pack ( //obstyp(:)% name, (/ .true., .false. /)) ! ICE
!print *, pack
--- Comment #2 from joseph at codesourcery dot com 2009-08-25 16:23 ---
Subject: Re: [4.5 Regression] Syntax error: Unterminated
quoted string
On Tue, 25 Aug 2009, rwild at gcc dot gnu dot org wrote:
AFACIS, the bug is in the test_summary script, it tries to parse the
internals of
--- Comment #3 from rwild at gcc dot gnu dot org 2009-08-25 16:32 ---
(In reply to comment #2)
value_of_substed=`echo @substed@ | ./config.status --file=-`
It's a bad idea for the script to depend at all on either config.status or
a build tree
I don't understand this remark.
--- Comment #4 from joseph at codesourcery dot com 2009-08-25 16:58 ---
Subject: Re: [4.5 Regression] Syntax error: Unterminated
quoted string
On Tue, 25 Aug 2009, rwild at gcc dot gnu dot org wrote:
--- Comment #3 from rwild at gcc dot gnu dot org 2009-08-25 16:32 ---
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-25 17:02 ---
internal compiler error: in gfc_typenode_for_spec
That's the unreachable() due to: spec-type == BT_UNKNOWN.
Debugging shows that gfc_typenode_for_spec is called by
gfc_conv_expr_descriptor where erxp-expr_type ==
--- Comment #15 from tkoenig at gcc dot gnu dot org 2009-08-25 17:05
---
Subject: Bug 34670
Author: tkoenig
Date: Tue Aug 25 17:05:10 2009
New Revision: 151085
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151085
Log:
2009-08-25 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-08-25 17:09 ---
Without checking, I'd expect it's not only PRODUCT, but all of the intrinsics
allowed in init-expr by F2003.
Offhand I'd blame expr.c (check_transformational), in particular:
2151 functions =
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-08-25 17:37 ---
It turns out, that the PRODUCT is already simplified to EXPR_CONST before is is
checked in expr.c (check_init_expr).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41165
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #9 from pault at gcc dot gnu dot org 2009-08-25 18:55 ---
Subject: Bug 41062
Author: pault
Date: Tue Aug 25 18:54:58 2009
New Revision: 151092
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151092
Log:
2008-08-25 Paul Thomas pa...@gcc.gnu.org
PR
Probably since the introduction of those two patches
2009-07-27 Tobias Burnus bur...@net-b.de
PR fortran/40863
* c99_functions.c: Define complex I, if not defined.
Create prototypes for C99 functions to silence warnings.
* gfortran.map: Add missing functions to
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-25 20:47 ---
That problem is very similar to the one on AIX, namely, complex.h is broken.
I think the proper fix is to use fixinclude. For AIX the following patch worked
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00844.html
I
for the exemple below g++ does not generate any DIE representing the namespace
which name is not_emitted.
struct strukt
{
int m;
};
namespace not_emitted
{
typedef strukt T;
}
int
main()
{
not_emitted::T t;
t.m = 0;
return 0;
}
--
Summary: namespace DIE not generated
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #8 from spop at gcc dot gnu dot org 2009-08-25 21:03 ---
Disabling one of the useless gcc_asserts that verifies the consistency of the
original representation before any transform, I am down to 0 seconds for the
data dependence test, and the following compile times for
--- Comment #1 from dodji at gcc dot gnu dot org 2009-08-25 21:08 ---
Created an attachment (id=18424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18424action=view)
fix candidate
I am testing this patch ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
--- Comment #2 from dje at gcc dot gnu dot org 2009-08-25 21:32 ---
Just follow the style that Steve Ellcey and I used for HPUX and AIX. You
basically should be able to take either of our stanzas in inclhack.def and
substitute the regex in the select line that matches Solaris (and
--- Comment #16 from dominiq at lps dot ens dot fr 2009-08-25 21:25 ---
After some discussion on IRC with Tobias Schlüter, it seems that the problem
comes from bad optimizations that are broken by chance with the original code.
Commenting line 139:
WRITE (6,*) i , spx(i) ,
When I compile the following code
void f(int *x, int *y){
*x = 7;
*y = 4;
}
at -O2 for Itanium, I get the following assembly:
f:
.prologue
.body
.mmi
addl r14 = 7, r0
;;
st4 [r32] = r14
addl r14 = 4, r0
;;
.mib
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
1 - 100 of 119 matches
Mail list logo
