--- Comment #1 from ubizjak at gmail dot com 2007-09-19 06:20 ---
I'll backport http://gcc.gnu.org/viewcvs?view=revrevision=128328 from PR
target/33369 to fix this issue.
*** This bug has been marked as a duplicate of 33369 ***
--
ubizjak at gmail dot com changed:
What
--- Comment #7 from ubizjak at gmail dot com 2007-09-19 06:20 ---
*** Bug 33482 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
===
void foo()
{
if (throw 0)
;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: error: could not convert 'throw((__cxa_allocate_exception(4u),
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-09-19 06:40
---
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
Sorry, that's actually since GCC 3.0.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
==
templateint void foo() { delete 0 ? 1 : 0; }
==
bug.cc: In function 'void foo()':
bug.cc:1: error: could not
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33493
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 3.4.0:
==
templateint void foo(int(*f=0)());
==
bug.cc:1: error: variable or field 'foo' declared void
bug.cc:1: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33494
The C++ frontend generates a broken diagnostic for the following code
snippet since GCC 4.0.0:
==
void foo()
{
if (({while(true);}))
;
}
==
bug.cc: In function 'void foo()':
bug.cc:3: error: could not
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33495
The following invalid code snippet triggers an ICE on mainline:
==
templateint... N void foo()
{
sizeof...N();
}
void bar()
{
foo0();
}
==
bug1.cc: In function 'void foo()':
bug1.cc:3: error: 'N' cannot
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33496
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-19 09:16
---
For some reason, I had completely forgotten about ldexp(). But as it is C89, it
should be available, and as all GCC supported targets now have (FLT_RADIX ==
2), it should fix the problem. John, could you confirm
--- Comment #3 from tbm at cyrius dot com 2007-09-19 09:21 ---
Still there as of trunk 20070916.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
--- Comment #3 from jbeulich at novell dot com 2007-09-19 09:39 ---
Isn't this the same as 16602 (which I don't really understand why it was
rejected as invalid)? Also, if this *is* invalid, then what proper mechanism
does one have to express what is intended here? And why does similar
--- Comment #2 from E dot Kuemmerle at fz-juelich dot de 2007-09-19 09:40
---
Here is a self-contained example:
templateclass T, int Sz
class Vector {
public:
explicit Vector() {}
~Vector() {}
private:
T m_data[Sz];
};
int main() {
--- Comment #2 from schwab at suse dot de 2007-09-19 09:47 ---
*** Bug 33076 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #4 from schwab at suse dot de 2007-09-19 09:47 ---
*** This bug has been marked as a duplicate of 16602 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-19 09:54
---
(In reply to comment #0)
Following a discussion on IRC with FX Coudert, I think the number of digits
printed by default in formatted output should be increased by one.
Dominique, what is the output of your
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|enhancement |normal
Component|fortran |libfortran
--
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 #3 from bonzini at gnu dot org 2007-09-19 11:46 ---
I'm not convinced by the explanation in the comment. A pointer to array *is*
compatible with the corresponding const pointer type; -Wcast-qual may apply
too, but that's not exhibited in the test case.
--
bonzini at gnu
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-19 11:52
---
Mine. A straightforward patch following the idea laid in my previous comment
fixes it.
Index: arith.c
===
--- arith.c (revision 128540)
+++
See http://gcc.gnu.org/ml/fortran/2007-09/msg00301.html
for the initial bug report by Salvatore Filippone (thanks for finding the bug!)
and a longer example.
Assume the following code:
type double_vector_item
real(c_double), allocatable :: v(:)
end type double_vector_item
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #8 from dir at lanl dot gov 2007-09-19 12:47 ---
Still Crashing on the 20070917 version -
[dranta:~/fe/dyna3d96/source] dir% gfortran -fcray-pointer -fno-automatic -g
-O0 -c -DSGI -DWKSTN -DUNIX -DVECLEN=32 -DDP out.f
outt.F:3155.19:
common/aux14/
--- Comment #7 from jakub at gcc dot gnu dot org 2007-09-19 12:55 ---
This no longer reproduces on the trunk since
http://gcc.gnu.org/viewcvs?root=gccview=revrev=128272
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33140
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-19 12:38 ---
Subject: Re: Add one digit to the default formatted output
Dominique, what is the output of your test program on ppc-darwin?
real(4)
default 808
1PG20.61881
1PG20.7 808
1PG20.8
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-19 13:18
---
(In reply to comment #6)
As this PR shows, this user error happens easily, if one converts a fixed-form
into a free-form code. Thus I'm in favour of printing a warning or - as ifort
and sunf95 do - an error.
--- Comment #9 from dir at lanl dot gov 2007-09-19 13:39 ---
It works Ok on my version of linux, but it still is crashing on today's
Macintosh PowerPC version (20070919) -
[dranta:~/fe/dyna3d96/source] dir% gfortran -g -c -O0 -fcray-pointer
-fno-automatic out.f
outt.F:3155.19
--- Comment #8 from burnus at gcc dot gnu dot org 2007-09-19 13:46 ---
(In reply to comment #6)
Pedantically this is not a bug. If an omp sentinel doesn't have the desired
form, it should be handled as a normal comment.
I cannot find anything about this in the OpenMP spec; I think
--- Comment #2 from janis at gcc dot gnu dot org 2007-09-19 14:15 ---
A regression hunt on powerpc-linux using the submitter's test case identified
the following patch where the test starts failing:
http://gcc.gnu.org/viewcvs?view=revrev=126399
r126399 | mmitchel | 2007-07-06
--- Comment #10 from dir at lanl dot gov 2007-09-19 13:55 ---
It looks like it is now only a Macintosh PowerPC version problem. It also works
Ok on the Intel Macintosh and on the MSYS versions of gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-19 14:28 ---
(In reply to comment #6)
It looks like
zlib compiled w/ -O -msse -ftree-vectorize (built with fedora's rpm package
gcc-4.1.2-17)
has same problem.
In my environment, rpm-4.4.2.1-7.fc8 and seamonkey-1.1.3-6.fc8
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #9 from jakub at gcc dot gnu dot org 2007-09-19 14:11 ---
Well, it is the Fortran standard that says free form comments start with !
And then OpenMP2.5 2.1.2 goes on and says certain forms of comments are not
to be treated as comments, but OpenMP directives etc.
One of them
--- Comment #12 from alex dot d at bugmenot dot com 2007-09-19 14:38
---
I've a similar problem when building SDL library (1.2.12), when using -O3
compilation flag. I'll try to attach an .i file that triggers the bug. After
starting the compilation, the memory starts getting consumed
--- Comment #13 from alex dot d at bugmenot dot com 2007-09-19 14:43
---
Created an attachment (id=14223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14223action=view)
consumes all memory when compiled with -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32199
--- Comment #3 from pcarlini at suse dot de 2007-09-19 14:43 ---
Thanks a lot!
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
gcc-4.2.0 and gcc-4.2.1 cannot compile properly this function if -O2 is
selected
It generates an infinite loop :(
No problem for previous version (gcc-4.1.2 is OK)
$ cat bug.c
void table_init(int *value)
{
int i;
int val = 0x03020100;
for (i = 0; i 256/4; i++) {
--- Comment #4 from pcarlini at suse dot de 2007-09-19 15:17 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-19 15:59 ---
Technically the testcase invokes undefined behavior because 'val' overflows
during loop execution. Practically from a QOI point of view the undefinedness
should not propagate to the loop exit test (though GCCs
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-19 16:12 ---
Technically, the code is undefined (overflow of signed integer val). Using -O2
-fno-strict-overflow results in a loop test, but the code looks dubious:
table_init:
pushl %ebp# 51*pushsi2
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-19 15:53 ---
Confirmed. IVOPTs chooses to replace the exit test by one that is true
only after signed overflow. SCEV/VRP happily optimizes this away.
bb 2:
ivtmp.52_2 = (long unsigned int) value_8;
# ivtmp.52_16 = PHI
When I compile the module listed below I get the following messages:
c.f90:9.28:
MODULE PROCEDURE cx_cadr, cx_radc
1
Error: FUNCTION result cx_cadr can't be of type TYPE(cx) in FUNCTION cx_cadr at
(1)
c.f90:19.18:
END MODULE complex
1
Error:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-19 16:35 ---
what happens when val is turned into unsgned?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rask at gcc dot gnu dot org 2007-09-19 16:39 ---
table_init:
pushl %ebp# 51*pushsi2[length = 1]
movl$117835012, %eax# 20*movsi_1/1 [length = 5]
movl%esp, %ebp # 52*movsi_1/1 [length = 2]
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-09-19 16:45 ---
Mine.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-19 16:50 ---
And the code here is undefined as val does overflow.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rakdver at gcc dot gnu dot org 2007-09-19 16:56 ---
t #2)
Technically the testcase invokes undefined behavior because 'val' overflows
during loop execution. Practically from a QOI point of view the undefinedness
should not propagate to the loop exit test (though
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC||bkoz at redhat dot com
Status|UNCONFIRMED
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-09-19 16:59 ---
Hey Chalathip, thanks for your comments. I've fixed all of these except for:
Suggestion: null_probe_fn class is missing.
As that file has no corresponding .svg file and thus I cannot edit it.
best,
benjamin
--
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-09-19 16:59 ---
Also, this one.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
[EMAIL PROTECTED] cat bug070919.f90
subroutine whatever()
logical(kind=1) :: l1, l2, l3
if ((l1 .and. l2) .neqv. l3) then
l1 = .true.
endif
end
[EMAIL PROTECTED] gfortran -c bug070919.f90
bug070919.f90: In function ‘whatever’:
bug070919.f90:1: internal compiler error: in copy_to_mode_reg, at
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-19 17:05 ---
Awesome: thanks for doing these PR's Wolfgang.
Andrew, you mean the attribute?
It's my preference to use #pagma GCC system header for this. It does the least
amount of molestation.
However, it doesn't currently
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-19 17:05 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-19 17:06 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-09-19 17:07 ---
Wolfgang means parallel mode instead of debug mode.
This is confirmed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
CC||bkoz at redhat dot com
Status|UNCONFIRMED
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-19 17:08 ---
(In reply to comment #3)
Awesome: thanks for doing these PR's Wolfgang.
Andrew, you mean the attribute?
No.
I mean something like:
int f(int n)
{
__extension__ int h[n];
h[n-1] = 0;
return h[n-1];
}
--- Comment #4 from raeburn at raeburn dot org 2007-09-19 17:27 ---
(In reply to comment #3)
I'm not convinced by the explanation in the comment. A pointer to array *is*
compatible with the corresponding const pointer type; -Wcast-qual may apply
too, but that's not exhibited in the
--- Comment #4 from jakub at gcc dot gnu dot org 2007-09-19 17:30 ---
I think the standard is very vague here.
First consider:
!$omp parallel default(none)
call something
!$omp do schedule(static, chunksize)
do i=1,100
call somethingelse
done
!$omp end do
!$omp end parallel
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-09-19 17:33
---
Don't we/can't we issue a warning here?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-19 17:46
---
Confirmed on x86_64-linux.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
GCC 4.2.1 assumes that undefined classes have public copy constructors (at
least when they are used in template classes), as evidenced in the code below.
GCC 4.1.0 generates a compiler error for the same code.
begin gcc_error2.cpp
class A;
template
--- Comment #1 from sfilippone at uniroma2 dot it 2007-09-19 17:29 ---
A version with an inner pointer to a derived type instead of allocatable array
fails as well.
-
module c_vhandle_mod
use iso_c_binding
type foo
integer :: i
end type foo
type foo_item
--- Comment #27 from eweddington at cso dot atmel dot com 2007-09-19 17:57
---
Created an attachment (id=14224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14224action=view)
Rask's patch modified from comments.
Here is Rask's patch again, but slightly modified from the
--- Comment #8 from andreast at gcc dot gnu dot org 2007-09-19 18:08
---
Fixed
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from andreast at gcc dot gnu dot org 2007-09-19 18:09
---
Fixed
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pcarlini at suse dot de 2007-09-19 17:59 ---
Hi again... A regression hunt would be useful for this one too...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from singler at ira dot uka dot de 2007-09-19 18:34 ---
Instead of std::plus, a functor should be used that accepts two different types
for LHS and RHS, Result and
std::iterator_traitsRandomAccessIterator::value_type, respectively.
--
singler at ira dot uka dot de
--- Comment #1 from singler at ira dot uka dot de 2007-09-19 18:42 ---
The standard states clearly (24.3.1):
Accordingly, it is required that if Iterator is the type of an iterator, the
types
iterator_traitsIterator::difference_type
iterator_traitsIterator::value_type
--- Comment #6 from kargl at gcc dot gnu dot org 2007-09-19 18:48 ---
I have a patch that in theory allows the repeat count
to be unlimited. I'll note that having a large repeat
count is a rather illogical thing to do, based on my
previous posts about compile time and size of
~ gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /projects/tob/gcc/configure --enable-languages=c,fortran
--prefix=/projects/tob/gcc-trunk
Thread model: posix
gcc version 4.3.0 20070919 (experimental) [trunk revision 128597] (GCC)
~ cat fm.F
end
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-19 18:58 ---
#define have to be understood by the front-end with -g3
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2007-09-19 19:04 ---
As I've said in the other report, I believe you shouldn't rely on the
existence of iterator_traits for the iterator type. You should use the
return type of dereferencing the iterator.
W.
--
--- Comment #2 from william dot mitchell at nist dot gov 2007-09-19 19:07
---
If it helps, this bug was not in GNU Fortran (GCC) 4.3.0 20070531
(experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33500
--- Comment #2 from bangerth at dealii dot org 2007-09-19 19:11 ---
(In reply to comment #1)
That this is missing in the requirement lists in 24.1.1 and 24.1.2 is probably
due to the fact that it does not concern the Iterator class itself, but
iterator_traitsIterator.
I disagree
--- Comment #5 from joseph at codesourcery dot com 2007-09-19 19:54 ---
Subject: Re: Warning when passing a pointer to a const array
to a function that expects a pointer to a non-cast one
On Wed, 19 Sep 2007, jbeulich at novell dot com wrote:
Isn't this the same as 16602 (which I
snapshot gcc-4.3-20070914
When i try to build gcc the process falls when it tries to use just created
binutils or gas. Investigating the problem I've found that libtool creates
normal binutils in binutils/.libs directory and creates a wrapper in binutils
directory for each util. The wrapper should
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|other |bootstrap
--- Comment #9 from gjunk at sapience dot com 2007-09-19 21:34 ---
Thanks for feedback - not exactly sure where this leaves things - but if gcc
can deliver the same kind of floating point performance as icc it would be a
really good thing.
The 2005 article - wasn't clear to me what
--- Comment #7 from dgregor at gcc dot gnu dot org 2007-09-19 21:45 ---
Here is the real fix:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01544.html
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-09-19 21:45 ---
Here is the real fix:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01544.html
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
looks like there is an ugly bug in g++ front-end.
the problem can be demonstrated by the existing testcase:
ext/pb_ds/regression/trie_data_map_rand.cc
if you apply the following diff:
.../libstdc++-v3/testsuite/util/regression/rand/assoc/detail/ $ svn di
Index: insert_fn_imps.hpp
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-09-19
21:52 ---
With 4.1, 4.2 and trunk, there is still no diagnosis of change in calling
convention in decl, but the bug in generated code is exposed only with
-fno-unit-at-time.
Danny
--
dannysmith at users dot
As reported in http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01505.html
The spu target builtins are not GC safe.
--
Summary: Vectorizer (or spu target builtins) and PCH don't get
along
Product: gcc
Version: 4.3.0
Status:
--- Comment #2 from patchapp at dberlin dot org 2007-09-19 23:15 ---
Subject: Bug number PR 33497
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01583.html
--
extern int foo (char *) __attribute__ ((warn_unused_result));
extern int bar (char *) throw () __attribute__ ((warn_unused_result));
extern int bar (char *) throw ();
fails to compile with 4.2/4.3 (instead of warn_unused_result
any other attribute that has type_required set can be used, like
--- Comment #3 from janis at gcc dot gnu dot org 2007-09-19 23:20 ---
A regression hunt on powerpc-linux using the submitter's test case identified
the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=115800
r115800 | lmillward | 2006-07-28 17:01:19 + (Fri, 28 Jul
--- Comment #5 from yuri at tsoft dot com 2007-09-19 23:37 ---
I would like to note that this isn't a clear-cut suggestion for the following
reasons:
* It's impossible to enforce such warning in all cases, only in case of virtual
functions immediately called from constructor/destructor.
--
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 #2 from pinskia at gcc dot gnu dot org 2007-09-20 00:46 ---
I think this is a dup of bug 14933.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33473
--- Comment #3 from rswan at signetic dot ca 2007-09-20 01:10 ---
(In reply to comment #2)
I think this is a dup of bug 14933.
I agree. Sorry. Should I mark it as a duplicate?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33473
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-20
02:24 ---
Subject: Re: fallback scalbn doesn't handle denormals correctly
For some reason, I had completely forgotten about ldexp(). But as it is C89,
it
should be available, and as all GCC supported targets
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-20 03:25
---
Un-assigning myself. No time at the moment
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-20 03:33
---
I am investigating.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bangerth at dealii dot org 2007-09-20 03:35 ---
Confirmed. We use to error out but don't do any more with gcc4.1.2. icc
does produce an error, but Sun Studio doesn't (though I have other beef
with that latter compiler as well...)
W.
--
bangerth at dealii dot org
1 - 100 of 101 matches
Mail list logo
