--- Comment #1 from pault at gcc dot gnu dot org 2007-03-17 07:26 ---
The aliasing of the arguments to subroutine set results in the initialization
of the intent(out) also being applied to the intent(in) argument.
I feel a temporary coming on.
Paul
--
pault at gcc dot gnu dot org
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-03-17 07:30
---
Probably uncovered by disabling VRP...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-03-17 07:33
---
I have to rerun the ACATS tests with more disk space available. After the C3
tests all other failures were due to disk full.
OK, please report the results of a complete run.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-17 07:38 ---
This is related to PR 14771, most likely the parentheses are being ignored.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
Just a meta-bug to keep track of problems with
TRANSFER. Most of these should go away once we
write (and call) gfc_simplify_transfer.
--
Summary: [meta-bug] TRANSFER intrinsic
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity:
--- Comment #17 from ubizjak at gmail dot com 2007-03-17 09:45 ---
(In reply to comment #16)
As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks
Richard for your
patience.
I have just noticed the following oddity with the code:
[karma] bug/cexp_pb% g++-4
Build the following code with gcc -std=c99 -Wall -Wextra -Werror -Os -S:
void q(const unsigned int);
void f() {for (unsigned int x = 0; x != 10; ++x) q(77);}
The loop becomes:
.L2:
subl$12, %esp
incl%ebx
pushl $77
callq
addl$16, %esp
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-17 10:18 ---
This fixes it and regtests OK - will submit later on
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 122943)
---
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #90 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:24
---
Closing as fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:30
---
Subject: Bug 31184
Author: fxcoudert
Date: Sat Mar 17 11:30:20 2007
New Revision: 123018
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123018
Log:
PR fortran/31184
* invoke.texi: Fix typo.
building gcc on opensolaris fails. the build attempts to build a 64 bit
compiler on a 32 bit system..
gmake
GCC_FOR_TARGET=/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc/xgcc
-B/export/home/error404/Code/gcc-4.1.1/host-i386-pc-solaris2.11/gcc/
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:32
---
Subject: Bug 31184
Author: fxcoudert
Date: Sat Mar 17 11:31:52 2007
New Revision: 123019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123019
Log:
PR fortran/31184
* invoke.texi: Fix typo.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:33
---
Subject: Bug 31184
Author: fxcoudert
Date: Sat Mar 17 11:32:56 2007
New Revision: 123020
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123020
Log:
PR fortran/31184
* invoke.texi: Fix typo.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:34
---
Fixed on all active branches. Thanks for the report, documentation bug-reports
are an important feedback to us!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:36
---
Confirmed. We have to be careful how that interacts with user-installed signal
handlers, but it's otherwise a good idea.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-17 11:39
---
Confirmed as an possible enhancement, though I agree there a both pros and
cons. (My personal opinion is that I prefer the fixed-width version.)
--
fxcoudert at gcc dot gnu dot org changed:
What
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-17 12:29 ---
Subject: Re: __builtin_cexpi is broken on Darwin
This is PR middle-end/30666. Patch for this problem is waiting for review.
Thanks for the answer. I did not worried about the warn, but was only
in the mode I
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 13:01
---
(In reply to comment #3)
The front end is converting the integer8 to integer4 and not checking the
range
of the number first.
Every time a unit number is used, there should be a check to be sure it's in
the
Without option and when compiled with the 20070316 snapshot on OSX 10.3.9
gcc/testsuite/gfortran.dg/pointer_intent_1.f90 yields an executable
which segfault, see:
http://gcc.gnu.org/ml/fortran/2007-03/msg00345.html
but ignore the crash log I have posted. The right one is:
**
Host Name:
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-17
13:44 ---
Subject: Re: Bootstrap comparison error at revision 122821
int foo (unsigned int i)
{
int j = 12048173;
if (i 32)
{
j = j i;
if (j 0)
return 0;
}
return 1;
A simple code that adds a 'value' too all the elements of an array should
generate post increments while loading/storing values from/into the array. The
code looks something like this
for (i = 0; i 10; i++) {
*(intArray++) |= value;
}
However a post increment is not generated at O3 ( that
--- Comment #21 from ghazi at gcc dot gnu dot org 2007-03-17 14:12 ---
I get similar make compare errors on sparc-sun-solaris2.10. Reverting the
bit from comment#15 fixes it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-03-17
14:13 ---
Created an attachment (id=13218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13218action=view)
Source that exposes the mentioned deficiency in the compiler
--
Hello,
there seems to be a gcc problem with the target 'bfin-elf':
/home/mstein/sim/bfin-elf/build/./gcc/xgcc
-B/home/mstein/sim/bfin-elf/build/./gcc/ -nostdinc
-B/home/mstein/sim/bfin-elf/build/bfin-elf/newlib/ -isystem
/home/mstein/sim/bfin-elf/build/bfin-elf/newlib/targ-include -isystem
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-17 14:20
---
Created an attachment (id=13219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13219action=view)
from SVN revision: 123001
Commandline used to create fp-bit.i:
--- Comment #6 from dorit at gcc dot gnu dot org 2007-03-17 14:43 ---
Subject: Bug 31041
Author: dorit
Date: Sat Mar 17 14:43:30 2007
New Revision: 123023
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123023
Log:
PR tree-optimization/31041
* tree-vect-transform.c
The string lengths are truncated to 32-bit
values here, which shouldn't happen.
$ cat substr.f90
program main
character (len=2_8**32_8+4_8) :: ch
ch = ' '
print *,ch(1:2_8**32_8+3_8)
end program main
$ gfortran -fdump-tree-original substr.f90
$ cat substr.f90.003t.original
MAIN__ ()
{
$ cat data.f90
program main
integer(kind=1), dimension(4294967296_8) :: i
data i /4294967296_8 * 1_1/
print *,i(1)
end program main
$ gfortran data.f90
data.f90:3.24:
data i /4294967296_8 * 1_1/
1
Error: Integer value too large in expression at (1)
This is probably
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 15:27 ---
I can reproduce the problem, but this is a duplicate of PR 29397.
Closing (but thanks anyway!)
*** This bug has been marked as a duplicate of 29397 ***
--
tkoenig at gcc dot gnu dot org changed:
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-17 15:27 ---
*** Bug 31206 has been marked as a duplicate of this bug. ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 15:36 ---
Confirmed.
Reduced test case:
$ cat rewind-2.f90
program main
write (*,'(A,T1,A)',advance=no) 'XX','ABC'
end program main
$ gfortran rewind-2.f90
$ ./a.out
ABC$
Jerry, I'm putting you on the CC list for
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 15:42 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
This is my simple test proggie.
test1 is always ok, but test2 fails with -O3 (produces output 1 0 0 0 for
test2), but -O2 makes it behave.
I am on x86_64. -m32 has interesting effects:
-O3 -Wall -m32 -msse2 -march=i486 is ok (output 1 0 3 0, as expected)
-O3 -Wall -m32 -msse2 -march=i586 is
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-17 15:52 ---
This fixes the bug (and PR31209) and regtests OK. Will package it up as a
submission tomorrow morning.
Index: gcc/fortran/trans-expr.c
===
***
--- Comment #1 from prakash at punnoor dot de 2007-03-17 15:52 ---
Created an attachment (id=13220)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13220action=view)
test2 triggers bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-03-17 15:59
---
I have started looking at this. I believe its a duplicate of 31199. In using
advance=no we are failing to retain or use the information about the maximum
position reached during preceding writes.
*** This bug
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-17 15:59
---
*** Bug 31207 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-17 16:34 ---
What options are passing to configure? Do you have CFLAGS set?
Second i386-solaris is a multilibed target which means it will build the 64bit
libraries even on a 32bit machine. If you don't want that, then use
Compiling the following with -Wunreachable-code -D_GLIBCXX_DEBUG
--
#include vector
int main()
{
std::vectorint::iterator a;
}
--
produces the warning :
--
--- Comment #2 from prakash at punnoor dot de 2007-03-17 16:49 ---
Created an attachment (id=13221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13221action=view)
test2 triggers bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31245
--- Comment #3 from prakash at punnoor dot de 2007-03-17 16:51 ---
Sorry, I uploaded the wrong test case. In fact changing the unaligned load to
aligned load triggers the bug, which the new file represents in a shorter
notation, I guess.
--
This is an accepts invalid code report.
The following code happens to compile with g++ (all versions),
whereas the standard does not guarantee it should (I think).
#include vector
typedef std::vectorint::iterator Iterator;
Iterator::value_type v;
Iterator::pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-17 16:58 ---
Lets look at the IR:
;; Function __gnu_debug::_Safe_iterator_Iterator, _Sequence::_Safe_iterator()
[with _Iterator = __gnu_cxx::__normal_iteratorint*, __gnu_norm::vectorint,
std::allocatorint , _Sequence =
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-17 17:00 ---
IIRC iterator is an implemention defined type so this is valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
--- Comment #2 from chris at bubblescope dot net 2007-03-17 17:19 ---
Depending on how you read it, 24.3.1 looks to me like it might require that. It
says that iterator_traits is defined to include:
typedef typename Iterator::value_type value_type;
and that it is specialised for
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2007-03-17
17:26 ---
Trying further, I noticed that simply default constructing an std::vectorint,
even without the debug mode _GLIBCXX_DEBUG, generates also a bunch (14 !) of
these warnings.
Andrew, I did not follow all
--- Comment #4 from sh-list at ssc-studios dot com 2007-03-17 17:31 ---
so in other words you're saying the solution to this is
if you want it to work with GCC, make your code non-portable
afaik __attribute__ (( weak )) is not part of the standard, its not a
portable solution.
the
--- Comment #3 from sylvain dot pion at sophia dot inria dot fr 2007-03-17
17:35 ---
I'm not sure about the standard requirements. My user question is that
I want to develop with GCC as my main compiler, and I want it to catch
non-portability bugs as much as possible.
@Chris: note
--- Comment #3 from chris at bubblescope dot net 2007-03-17 17:46 ---
This is a general problem I've come across with templates. You commonly want to
try/catch around some operation, but when you have templated on a simple type,
like int, then it's easy to find out that no throwing can
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-17 17:47 ---
Well linker scripts are already non portable and not mentioned in the standard
and you are violating the C/C++ standards if the address of a variable is NULL
(0) :).
Also -O2 with -DUSETEMP gives the same results
--- Comment #4 from chris at bubblescope dot net 2007-03-17 17:52 ---
The main problem I can see with changing this is that you would have to decide
if you were going to remove the same options from the iterators of all other
standard containers. To not do so would seem to be
--- Comment #9 from roberto dot gordo at gmail dot com 2007-03-17 17:58
---
I would like to apologize for my faults in gcc bug report 31166, specially to
the people who responded, and fully acknowledge my error. I've misunderstood
your responses. Now, while reading them again, they
--- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-17
18:03 ---
Subject: Re: Bootstrap comparison error at revision 122821
I'll recheck with the third hunk.
j_5: [0, 12048173] EQUIVALENCES: { } (0 elements)
There isn't any difference in the code generated with and
--- Comment #4 from chris at bubblescope dot net 2007-03-17 18:07 ---
Here is a minimal code example:
#include new
int* get_ptr(void* ptr)
{
return new(ptr) int();
}
Which gives (on my computer)
/usr/include/c++/4.0.0/new: In function 'int* get_ptr(void*)':
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-03-17 18:45
---
Created an attachment (id=13222)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13222action=view)
Proposed patch
I think the attached patch would fix this bug. It's a significant rewrite of
the arith.c code
Following testcase produces unnecessary moves in short loop:
--cut here--
char table[256];
int test(void) {
char val = 0;
int i;
for (i = 0; i 10; i++)
val += table[i];
return val;
}
--cut here--
gcc -O2:
test:
.LFB2:
movzbl table(%rip), %ecx
movl$1, %edx
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-03-17 19:58
---
Subject: Bug 31120
Author: fxcoudert
Date: Sat Mar 17 19:58:37 2007
New Revision: 123028
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123028
Log:
PR fortran/31120
* trans-expr.c
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from johnsonnenschein at gmail dot com 2007-03-17 20:31
---
yes, you are correct, it was multilib. I tried again with that
Perhaps a check of isainfo(1) should be placed in the configure script to
ensure the target supports amd64 binaries ? Solaris runs on x86 32-bit or
--- Comment #5 from pcarlini at suse dot de 2007-03-17 20:40 ---
Note, however, that, as far as I can see, such try/catch are *not* in the
library code proper, but *all* synthesized by the C++ front-end. Is it so weird
to imagine for the C++ front-end to automatically suppress warning
--- Comment #6 from pcarlini at suse dot de 2007-03-17 20:48 ---
And I'm recategorizing as C++: either (as I strongly believe) a very general
diagnostic issue, or maybe a duplicate of C++/30500: certainly there is nothing
we can do on the library side to fix the implementation of
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-17 20:58
---
A two-lines fix for this bug:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 123028)
+++ gcc/fortran/trans-expr.c
With gfortran and g++ the computation of cos(x) and sin(x) is optimized by
taking
the real and imaginary parts of cexpi(x) (at least it is what I understand).
This is working
if and only if the computation of cexpi(x) is faster than the sum of the
separate computations
of cos(x) and sin(x).
Now
$ cat a4.f90
character(len=min(-4,5)) :: s
print *, len(s)
end
$ ./bin/gfortran -static a4.f90
a4.f90:1.31:
character(len=min(-4,5)) :: s
1
Error: 's' at (1) must have constant character length in this context
I tried with a few intrinsics, like MIN,
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
$ cat foo.f90
character(len=2.3) :: s
print *, len(s)
end
$ gfortran foo.f90
foo.f90:1.16:
character(len=2.3) :: s
1
Error: Expression at (1) must be of INTEGER type
foo.f90:1.16:
character(len=2.3) :: s
1
Error: Expression at (1) must be of INTEGER type
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--
Summary: ICE dans gfc_conv_constant, à fortran/trans-const.c:348
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
the fortran compiler crashes when trying to compile the following test program
:
subroutine probleme(p)
real(kind=8), dimension(:) :: p
integer :: nx = size(p, 1)
integer :: nix
nix = nx
end subroutine
The error reported by the compiler is :
test.f:
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-17 21:58
---
Created an attachment (id=13223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13223action=view)
the test program that fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-17 22:03
---
the attached program (test.f) fails to compile:
the compilation command is :
gfortran -c test.f
the error is :
test.f: In function probleme:
test.f:2: erreur interne du compilateur: dans gfc_conv_constant, à
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-03-17 22:06
---
Hi FX,
I'll look at this.
Looking at your patch, I have identified one
compile-time hog in complex_pow_ui:
$ time gfortran complex.f90
real3m35.506s
user3m35.329s
sys 0m0.156s
$ cat complex.f90
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-17 22:08 ---
Confirmed with 4.3.0.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-17 22:10 ---
Empty bug report, closing.
*** This bug has been marked as a duplicate of 31253 ***
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-17 22:10 ---
*** Bug 31252 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31253
--- Comment #24 from dberlin at gcc dot gnu dot org 2007-03-17 23:07
---
Subject: Bug 29922
Author: dberlin
Date: Sat Mar 17 23:07:34 2007
New Revision: 123029
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123029
Log:
2007-03-16 Daniel Berlin [EMAIL PROTECTED]
Fix PR
--- Comment #25 from tbm at cyrius dot com 2007-03-17 23:16 ---
Thanks, Danny!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
--- Comment #26 from dberlin at gcc dot gnu dot org 2007-03-17 23:18
---
Sorry for the delay.
Fixed now.
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from gdr at cs dot tamu dot edu 2007-03-17 23:35 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Note, however, that, as far as I can see, such try/catch are *not* in the
| library code proper,
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-17 23:39 ---
At the end of 14.6.3.3, Default initialization may be specified for a storage
unit that is storage associated provided the objects or subobjects supplying
the default initialization are of the same type and type
--- Comment #7 from matt at galloway dot me dot uk 2007-03-18 01:06 ---
Same problem for me with gcc-4.0.1. Is this going to get fixed or is it correct
behaviour and the code needs some sort of codeword to tell the compiler that
func2 is a template?
--
matt at galloway dot me dot uk
--- Comment #23 from daney at gcc dot gnu dot org 2007-03-18 01:55 ---
Reverting the hunk mentioned in comment #15 also allows mipsel-linux to
bootstrap.
I bootstrapped R122924 which failed in the stage2 stage3 compare. I then
reverted said hunk, and re-bootstrapped successfully.
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-03-18 02:22
---
Heres the real problem:
Try compiling this with and without -fno-range-check.
integer*8 :: k= 68719476746
integer*8 :: k2 = 2_8**36 + 10
print *, k=,k, k2, int(k2, kind=8), int(k2, kind=4)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-18 05:29 ---
You are wrong. The casts are correct as char + char in C is actually defined
as (int)(char) + (int) (char) aka promoted to int while doing the addition so
what the optimizers do when it sees (char)((int)(char) +
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 05:38 ---
I agree with you Paolo. The front-end should make sure that its
artefacts don't adversily affect diagnostics we emit.
I agree to some extend. The reason why the try/catch is there is because of
what the C++
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-18 06:12 ---
The work around is doing:
get_a().template func2 int();
Which tells the compiler for sure func2 is a template.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000
93 matches
Mail list logo
