--- Comment #2 from gerolf dot wendland at nsn dot com 2009-08-26 06:55
---
(In reply to comment #1)
> That would require that the ABI specifies such a mangling. I'm not sure
> anyone wants to go that route.
This is exactly what I had in mind. Slightly extended names for
structs/classe
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-26 06:41 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01405.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
--- Comment #5 from ubizjak at gmail dot com 2009-08-26 06:27 ---
FYI, this testcase also fails on alpha:
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
(I was not able to debug it properly, will wait for your reduced testcase...)
--
http://gcc.gnu.org/bugzilla/sh
C:\...>gcc -v
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.32/configure msdosdjgpp
Thread model: single
gcc version 4.3.2 (GCC)
Build command line: gpp -oexcpt -DTESTBADE excpt.C
Execute command line: excpt
The following source code is a pared down version of a short progra
--- Comment #6 from dwitte at mozilla dot com 2009-08-26 05:52 ---
Well, if it's comparing two existing types, sure. :)
How does it work in the case where the parser is dealing with the declaration
|bar_t func()|, and it wants to determine if it's seen the declaration of
|bar_t| before?
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-08-26 04:28 ---
(In reply to comment #4)
> Then how does the compiler determine type equality? By looking at the variant
> chain?
Easy pointer equality on TYPE_MAIN_VARIANT :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #4 from dwitte at mozilla dot com 2009-08-26 04:25 ---
Then how does the compiler determine type equality? By looking at the variant
chain? By determining the originating type somehow? If you can point me to the
procedure it uses to do this, perhaps we can duplicate it in our
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-08-26
03:49 ---
Does r151102 address the exponential code generation in graphite generally or
just that for this particular test case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
--- Comment #7 from hjl dot tools at gmail dot com 2009-08-26 03:33 ---
Please add a testcase before closing. Thanks.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-08-26 03:20
---
No bad news for a day, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-08-26 03:18 ---
Unlike C++, C does not inject foo_t if used as struct foo_t.
So I think this is correct behavior and really does not matter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-e500v2-linux-gnuspe
Configured with: ../configure --target=powerpc-e500v2-linux-gnuspe
--prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe
--with-sysroot=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnus
--- Comment #3 from bdavis at gcc dot gnu dot org 2009-08-26 02:18 ---
Subject: Bug 28093
Author: bdavis
Date: Wed Aug 26 02:18:14 2009
New Revision: 151112
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151112
Log:
2009-08-22 Bud Davis
PR fortran/28093
--- Comment #2 from dwitte at mozilla dot com 2009-08-26 02:13 ---
Also, this bug applies to ENUMERAL_TYPEs and UNION_TYPEs in addition to
RECORD_TYPEs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
--- Comment #1 from dwitte at mozilla dot com 2009-08-26 02:09 ---
Created an attachment (id=18425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18425&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
--- Comment #10 from gkandhakumar at gmail dot com 2009-08-26 02:09 ---
(In reply to comment #4)
> You nee to provide all the *.h, *.incnc, and *.inc needed files also.
>
hi,i cant attach all files in this site. files having more than 1.9Mb. so
please tell me what can i have to do to a
gcc version 4.5.0 20090825 (experimental) (GCC)
I found this bug while working on static analysis tools for Mozilla (using the
plugin framework), where we access |tree| structures in the cfg. (For
reference, this is also filed as
https://bugzilla.mozilla.org/show_bug.cgi?id=511261.)
Consider
--- Comment #9 from gkandhakumar at gmail dot com 2009-08-26 02:05 ---
(In reply to comment #6)
> I just downloaded CPMD and built it under gfortran 4.4.1 and 4.5.0 (revision
> 151047) without trouble.
> Could you post the output of "gfortran -v" and indicate your platform.
>
hi, really
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2009-08-26 01:03
---
oops, you got it from equation.com. Hmm, I don't know much how they create
their distribution.Suggest you contact them and see what they think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41168
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2009-08-26 00:39
---
Works for me on latest trunk. 4.5
$ ./a.out
1234567890
end of file detected
Please post the output from gfortran -v and also the exact URL where you got
the download. The binaries from the wiki are unoffici
--- Comment #1 from nemet at gcc dot gnu dot org 2009-08-25 23:05 ---
It's also a regression if the load-immediates can dual issue. I.e. see below
how the code gets worse between sched1 and sched2 on octeon.
I am cc'ing Vlad in case he has some ideas.
;; ==
--- Comment #4 from jb at gcc dot gnu dot org 2009-08-25 22:17 ---
Updated patch fixing remaining fd_truncate issues with testsuite.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from spop at gcc dot gnu dot org 2009-08-25 21:58 ---
Subject: Bug 40965
Author: spop
Date: Tue Aug 25 21:58:20 2009
New Revision: 151102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151102
Log:
Remove legality test before any transform.
2009-08-25 Sebastian P
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
|
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
s
--- 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 ano
--- 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) , epx(
--- 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=18424&action=view)
fix candidate
I am testing this patch ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
--- 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 graph
--
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
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 wh
--- 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, 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 think one
Probably since the introduction of those two patches
2009-07-27 Tobias Burnus
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 GFORTRAN_C99_1.0
--- Comment #8 from aesok at gcc dot gnu dot org 2009-08-25 19:04 ---
Subject: Bug 34412
Author: aesok
Date: Tue Aug 25 19:03:53 2009
New Revision: 151094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151094
Log:
PR target/34412
* config/avr/avr.c (expand_epilog
--- Comment #10 from pault at gcc dot gnu dot org 2009-08-25 18:55 ---
Fixed on trunk and 4.4.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- 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=gcc&view=rev&rev=151092
Log:
2008-08-25 Paul Thomas
PR fortran/41062
* tra
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-25 18:32 ---
In principle, the correct type is (should be) set in resolve_operator:
case INTRINSIC_CONCAT:
if (op1->ts.type == BT_CHARACTER && op2->ts.type == BT_CHARACTER
&& op1->ts.kind == op2->ts.kind)
The following bug occurs only in the version of gfortran downloaded from
ftp://ftp.equation.com/gcc/gcc-4.5-20090820-32.exe.
When I compile and run the program listed below it prints:
1234567890
1234567890
end of file not detected
On every other port of gfortran it prints:
1234567890
end o
--
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 #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
--- 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 = (gfc_option.allow_std
--- 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=gcc&view=rev&rev=151085
Log:
2009-08-25 Thomas Koenig
PR libfortran/34670
--- 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 #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 #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 remar
--- 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
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 (obstyp(:
--- 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
AC_CON
--
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
--
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.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.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40224
--- 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.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
--
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=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=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=41089
--- 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=41087
--
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=41082
--
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=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=40808
--
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.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40535
--- 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
--
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:42 ---
Yes, this is confusing.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- 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: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 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:35 ---
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:34 ---
Confirmed.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:33 ---
That would require that the ABI specifies such a mangling. I'm not sure
anyone wants to go that route.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40527
--- 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 #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 #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 t
--- 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 #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 reconfirme
--- 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
m
--- Comment #1 from bangerth at gmail dot com 2009-08-25 15:24 ---
Confirmed:
-
template struct Base {
template class I {};
};
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 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=18423&action=view)
test file that illustrates failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164
--- 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> /home/bangerth/bin/x86/gcc-mainline/bin
--- 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
--- 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
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 =
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++
Thre
--- 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
--- 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=gcc&view=rev&rev=151081
Log:
2009-08-25 Janus Weil
PR fortran/41139
* pri
--- 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
cours
--- 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
--- 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 #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: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 decla
--- 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 #2 from bangerth at gmail dot com 2009-08-25 14:04 ---
Confirmed:
-
class A {
template struct s {
enum { value };
};
};
int i = A::s<10>::value;
-
This should produce an error but doesn't.
W.
--
ba
1 - 100 of 132 matches
Mail list logo
